An information centric network (ICN) is a conceptualization of a networking protocol stack, in particular layers 3 and above of a network protocol stack. CCN network as well as similar networks, such as, for example, named data networking (NDN) networks are particular architectures and implementations of an ICN network. ICN, CCN, and NDN networks are based on the premise of naming resources in these networks. In particular, the naming relates to the use of a globally shared namespace for objects that allows entities in these networks to retrieve any content of interest. NDN networks and CCN networks have similar architectures, and for sake of clarity, examples related to CCN networks are discussed herein below.
Within a CCN network, a name is utilized to identify a content object instead of an Internet Protocol (IP) address of the host of the content. In an IP network, routing is based on host names (e.g., source and destination addresses). In a CCN network by contrast, routing is based on a uniform resource identifier (URI) or similar identifier for a content object. CCN routing is performed hop-by-hop, using longest prefix matching on the CCN name. All communications seeking to access data are framed as a request and response transaction. A CCN client (e.g., executed by user equipment) sends a message referred to as a CCN interest packet/message to the nodes in the CCN network. An interest packet/message may herein be referred to simply as an “interest”. The nodes of the CCN network respond with a CCN object identified by a CCN name in the CCN interest. These CCN objects are returned via a CCN response referred to as a CCN content object (CO) packet/message. A CO message/packet may herein be referred to simply as a “CO”.
All content object packets are cryptographically signed by their initial provider. A CCN client can thus verify the integrity and authenticity of the content even if the packet comes from untrusted links or untrusted hosts. As a direct effect, CCN nodes in the CCN network are allowed to cache packets locally in a table called the content store (CS). When a CCN node receives a CCN interest packet, the CCN node can determine whether its local content store has the requested CCN object and, if so, can send the CCN object to the requesting CCN client. The look up in the content store is by the CCN name. If the CCN name is not found in the local content store, then the CCN interest is forwarded according to entries for the CCN name in a forwarding information base (FIB) of the CCN node.
Routing strategies in Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6) are not feasible in CCN because of the difference in the variable use for routing. In IP networks, routing is performed based on the endpoint. Thus, the routing space is limited by the number of addresses available in the protocol. In CCN the routing is based on names and although the domains can be similar to IP addresses, each device may have one or several names that can remain the same independently of where they are. In IP this is solved with external services that keep the mapping between the user and the endpoint address. However, in CCN this will not work because the device name should be always the same so the mapping cannot be performed, but instead huge routing tables should be kept to route any name.